<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Explaining my code',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/02/26.jpg" alt="Snow person" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion posts for the day:
	</p>
	<blockquote>
		<p>
			Yeah, I can see both sides of that too.
			Asking beforehand would taint the results, but doing it without asking leads to alarms being triggered.
		</p>
		<p>
			The template is used within <a href="https://notabug.org/y.st./y.st./src/master/build.php#L89">a loop that pulls in each file with page data one by one</a>.
			So the page files don&apos;t even reference the template.
			Instead, the page files just define arrays with data that is then <a href="https://notabug.org/y.st./y.st./src/master/source/closure.php#L337">substituted into the template</a>.
			All the pages use the same template, though <a href="https://notabug.org/y.st./y.st./src/master/source/closure.php#L57">meta information in the form of file paths is used to determine which navigation links to include</a>.
			It used to be that metadata in the pages&apos; code determined which navigation menus were included, but that was redundant, given that the navigation links follow the directory structure of the site.
		</p>
		<p>
			The code&apos;s a bit of a mess though.
			I work on cleaning it bit by bit when I have time, but it suffers from my evolving coding style.
			For example, I used to put whole paragraphs all on one line.
			I think I have that particular issue cleaned up now, even on all old pages, but there are no doubt other inconsistencies still present.
			I think it&apos;s a natural consequence of working on something for years without first deciding upon a clear style and sticking with it.
			But if I stuck with my old style, I wouldn&apos;t be able to learn from my past mistakes.
			For example, the keeping of entire paragraphs on a single line as mentioned above made it impractical to see what was changed in commits that correct, for example, misspellings and malformed $a[XHTML].
			For practicality moving forward, that had to be fixed.
			My use of closures is also a mess.
			I only use closures when I can&apos;t find a way to generalise a function as much as I think I should, which means anything I&apos;d put in a closure is sloppy and I want to replace it, but I don&apos;t yet know how.
		</p>
	</blockquote>
	<blockquote>
		<p>
			Working with $a[JSON] is often done client-side via JavaScript, but like you said, it can be used server-side via $a[PHP] as well.
			Server-side is always a better option for this, too.
			You don&apos;t know if your users even have a JavaScript-enabled Web browser, let alone have JavaScript enables.
			People using screen readers, for example, would appreciate having this done server-side instead of client-side.
		</p>
		<p>
			I fully agree about the necessity of encryption these days.
			Mostly, when I think of encryption, I think of network encryption, for keeping the $a[NSA] and $a[ISP]s out of things that aren&apos;t their business.
			However, encryption of data on a server is also important, as you mention, for keeping hackers from getting at data.
			Some types of data should be hashed though, instead of encrypted.
			For example, it&apos;s much safer to hash passwords than store them, be they stored encrypted or unencrypted.
		</p>
		<p>
			Unit tests are important as well.
			I regret not writing unit tests for all the functions and classes in the main library I power my work with.
			I ended up going back and writing unit tests for a lot of it later, but without still being in the mindset of knowing how exactly it was supposed to work due to having just written the code, the unit tests written much later don&apos;t cover everything.
			Still, having gone back to write the unit tests later caught a bunch of stupid little bugs.
			I can&apos;t help but think I might&apos;ve caught even more if I&apos;d written the tests right away like I should have.
		</p>
	</blockquote>
</section>
END
);
